fix(auth): reject gateway reauth account mismatch#69
fix(auth): reject gateway reauth account mismatch#69michiosw wants to merge 1 commit intofeat/cli-verbose-diagnosticsfrom
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
78f4ff9 to
cf72a15
Compare
f049192 to
258cfb8
Compare
258cfb8 to
7f700ff
Compare
61cef06 to
f4565b5
Compare
7f700ff to
2b3a4fc
Compare
f4565b5 to
6651771
Compare
2b3a4fc to
d01266e
Compare
d01266e to
168c746
Compare
6651771 to
346c1db
Compare
168c746 to
2f9f9c5
Compare
346c1db to
30ae407
Compare
tumberger
left a comment
There was a problem hiding this comment.
This detects the account mismatch, but the caller still treats it as a recoverable hosted-connect failure.
fetchConnectURLWithGatewayLoginFallback(...) returns the mismatch, but resolveCredentials(...) goes through the connectErr warning path, prints the warning, and then returns resolved, nil, so kontext start continues launching without those providers.
That doesn’t match the PR intent in the title/body (“reject gateway reauth account mismatch”) or the sample Error: behavior. I think this mismatch should be promoted to a hard failure instead of being swallowed as a warning-only connect error.

Summary
issuer#subject.Why
Hosted connect can open a browser that is signed into a different Kontext account. When that happens, retrying credentials is misleading and can point the user at the wrong account, so the CLI now stops with a clear mismatch message.
Before / After Terminal Capture
Before, a second browser login could silently switch the hosted-connect account while the CLI kept using the original session:
After, account drift is caught before retrying credentials:
Verification
go test ./...on this branch.